Simple GC - Safe Compilation

Xerox PARC 8/13/91 It is increasingly attractive to compile programming languages requiring garbage collection into a standard intermediate language. This allows readily available translators for the intermediate language to be used in targeting an increasing variety of architectures, and thus allows an implementation that is immediately portable across a variety of architectures. The intermediate language most commonly used for this purpose is the C programming language. Lisp, and others. In several cases, these are the only currently viable implementations of the respective language. The reason for this is no doubt that C compilers target more different architectures than translators for other candidate languages. Furthermore every major hardware manufacturer provides a C compiler, which can thus take advantage of all instruction timing information known to the hardware manufacturer. This makes it difficult for third party compilers for other languages to provide comparable performance. The following proposal also applies to other intermediate languages. However, due to the dominance of C as an intermediate language, we cast the proposal in terms of C. We are careful to state the proposal such that it is also applicable to handwritten C, both because this is useful in itself, and because any other proposal would be unrealistic. In order to facilitate the discussion, we refer to the original source language as L. A fundamental difficulty with using standard C in conjunction with a garbage collector is that the C compiler is unlikely to cooperate with the collector in any major way. It cannot be expected to generate tables describing data structure layout to the garbage collector, or to adhere to conventions that clearly identify pointers. In fact, it has no way to generate such information, since it is often difficult to generate or write C programs with reliable type information in the C source. Most C-generating compilers appear to emit misleading C type information. However, the C compiler is free to choose it's own data structure layout, at least for function activation records, thus making it essentially impossible for the L-to-C compiler to emit such information. A number of techniques have been proposed to eliminate the need for compiler generated data layout information. Edelson proposes a method based on explicit root registration [Edelson 90]. Most other approaches rely on conservatively traversing at least the program stack and registers, treating all bit patterns that correspond to object pointers as though they were objects pointers. Currently all approaches …